What's the benefit?

using ?dir=lib requires downloading the entire nixpkgs tarball

I see, will lazy-trees fix this?

I doubt, but don't take my word for it #162 (comment)

I see, will lazy-trees fix this?

It can and I think it should, but it's actually an orthogonal issue that's only blocked on lazy trees for development reasons. Taking away the parent directory does change the flake semantics, but I think that's for the better. To be continued.

This is going to take a while so I'm open to changing the input until git/github tree fetching is widely available, so I'm warming up to the idea of doing this, having rejected it before.

• Shrink inputs footprint further #90

I'll add a comment that explains things.

nixpkgs.lib contains an outdated version of lib somehow. Maybe its updater is broken.

seems like the actions has been failing, I opened nix-community/nixpkgs.lib#4 to try to fix that

I've thought about it for a bit and I really don't want a fragile Action to be in the critical path between flake-parts and module system updates.
You are free to push this in manually with follows, but it's not something I wish to push as the default.
Something pinned like an Hercules CI Effect would be an improvement, but I'd rather put my effort into solving the root cause, which is git tree support in fetchTree (ironic, considering the naming).

If you are using flake-parts then you probably are also using nixpkgs, just use inputs.flake-parts = { url = "github:hercules-ci/flake-parts"; inputs.nixpkgs-lib.follows = "nixpkgs"; }; and it will reuse your nixpkgs.

yep that's already what I'm doing for my projects, I just noticed it trying to download the whole nixpkgs while debugging #160

Using nixpkgs.lib also breaks our //lib.nix version check, at least until nix-community/nixpkgs.lib#5 is merged in our minimum supported nixpkgs.lib version.